home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 15910 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.3 KB
  1. Path: amd.com!usenet
  2. From: "Paul G. Schaaf, Jr." <paul.schaaf@amd.com>
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.lang.smalltalk
  4. Subject: Re: Will Java kill C++?
  5. Date: Mon, 08 Apr 1996 13:06:08 -0700
  6. Organization: Advanced Micro Devices
  7. Message-ID: <316971B0.FEF@amd.com>
  8. References: <3134D499.653E@ix.netcom.com> <313613B2.136E@ksopk.sprint.com> <4i7qhl$ik6@cronkite.seas.gwu.edu> <4iuhi7$fmf@sundog.tiac.net> <4iumap$mn5@hustle.rahul.net> <31582A45.3742@vmark.com> <3163C031.4FB1@esec.ch> <3164888D.2B01@concentric.net> <4kbfn8$1bu@news1.is.net>
  9. NNTP-Posting-Host: hqsp86.amd.com
  10. Mime-Version: 1.0
  11. Content-Type: text/plain; charset=us-ascii
  12. Content-Transfer-Encoding: 7bit
  13. X-Mailer: Mozilla 2.0 (WinNT; I)
  14.  
  15. Mark VanTassel wrote:
  16. > 
  17. > "Alan L. Lovejoy" <alovejoy@concentric.net> wrote:
  18. > 
  19. > >Bzzzt!  Not according to the benchmarks I've done.  Go benchmark the 
  20. > >factorial or fibonacci functions (implemented recursively) in both C and a 
  21. > >good Smalltalk.  You are in for a big surprise.
  22. > 
  23. > You're not seriously suggesting that a fibonacci series be programmed
  24. > recursively, are you??? 
  25.  
  26.    Read again what he said.  He is suggesting an experiment to test the speed 
  27. of recursion; not declaring viable implementation for Fibonacci.  But perhaps 
  28. you are correct in attempting to make this explicit for other readers:  DO 
  29. NOT USE RECURSION TO IMPLEMENT FIBONNACCI for anything other than 
  30. experimental purposes.  
  31.  
  32. > Have you looked at the number of operations involved in calculating, say, the 1000th term as vs a standard looping approach?
  33.  
  34.    That's exactly why he was using this as an example.  It is easy to program, 
  35. contains many iterations, and illustrates his point:  recursion is very fast 
  36. in Smalltalk.  
  37.  
  38. > I don't think this is a valid benchmark... (and I too fail to see how
  39. > Smalltalk can be faster than C++ except perhaps in bizarre special
  40. > cases)
  41. > 
  42. > - /\/\ark \/anTassel (mvantassel@teambca.com)
  43.  
  44.    Try his experiment and you will see a set of problems for which the speed of 
  45. Smalltalk compares to that of c/c++.  You may dismiss this set of problems as 
  46. "bizarre", but as the size of that set increases, so does its importance.  
  47.  
  48.   Many (note that I am not saying all) c/c++ programmers claim that "Smalltalk 
  49. is slow," and therefore dismiss it.  This is wrong for two reasons: 
  50.       1. If speed were the only measure of value we'd all 
  51.          be programming in Assembler (or tuning c compiler-
  52.          generated Assembler).  
  53.       2. Smalltalk is much faster than many people think.  
  54.  
  55. The fact is that Smalltalk can do a few things faster than c/c++, and some 
  56. things as fast.  I would also argue that most of the remaining things in 
  57. Smalltalk are not "significantly slower" than c/c++.  This point is debatable 
  58. as it depends upon the requirement of your domain.  
  59.  
  60. It would be nice if we all had the resources to evaluate each of these 
  61. languages fairly.  Smalltalk is shortchanged if the programmer writes only 
  62. c/c++-style code, just as c++ is shortchanged if the programmer writes only 
  63. c-style code.  
  64.  
  65. ---------------------------------+---------------------------------------------
  66. Paul Schaaf  http://www.amd.com  |"I was thrown out of college for cheating on
  67. AMD, Sunnyvale CA                | the metaphysics exam; I looked into the soul
  68. I don't speak for my company.    | of the boy next to me." -- Woody Allen
  69.